IBIS Macromodel Task Group Meeting date: 07 April 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo * Stephen Slater Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to send his "Clock Forwarding BIRD Discussion" presentation to the ATM list. - Done. - Arpad to email Steve Parker asking him to post Fangyi's presentation to the ATM work archives. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 31 meeting. Michael moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: DDR Clock Forwarding: Arpad noted that Walter had prepared a presentation on an alternate BIRD. He asked if Michael or Ambrish had feedback to share first. Ambrish said his group had been working on a counter proposal of their own and would need another week to draft it. Michael said he preferred to wait until after Walter's presentation, so any of his remaining questions could be stated in the context of Walter and Fangyi's proposals. Walter shared his "BIRD_DQ_DQS_Clocking" presentation. slide 2: Overview - Introduce a new BIRD that overloads the existing clock_times argument in GetWave so that it can be used as an input as well as an output. - As an input it can be: - Ignored (current behavior) - Can contain the DQS clock_times output - Can contain the DQS waveform output - One new AMI Reserved Parameter specifies how it is used as an input. slide 3: Background - For DDR5 (and clock forwarding applications in general) the skew between DQ (data) and DQS (clock) has two components: - The N*UI skew (e.g., from a DQS clock tree) - The fine skew to get the DQS clock at the center of the DQ eye. - It would be nice to have a DDR5 DQ Rx model that has both the DQ waveform and either a DQS clock ticks or DQS waveform, so the clock can be correctly located in each UI of the DQ waveform. - There are multiple clock forwarding interfaces, for example MIPI at 10G, and as you go to higher and higher speeds there's an increased need to model the interaction between the clock and data waveforms. At the lower speeds of DDR5, right now 4G to 6G, this might not be quite as important yet. The PI issues might not be that important for DDR5 yet, and some would argue that DQS clock ticks are sufficient for that. However, if we are going to enable clock forwarded applications, we should be able to handle higher speed system modeling that may require DQS and DQ waveforms. slide 4: Alternative BIRD - The clock_times argument passed to the DQ GetWave: - Content of clock_times as an input to the model is ignored (IBIS 7.0). - Content of clock_times contains the clock_times output of DQS GetWave. - Content of clock_times contains the waveform output of DQS GetWave. Stephen asked if this proposal was broadening the definition of clock_times in that it could contain clock ticks on input or the full DQS waveform. Walter agreed that it was. Walter noted that IBIS 7.0 behavior is that clock_times is only used as an output, so its contents on input to the model are ignored by the model. slide 5: New AMI Reserved Parameter Rx_Use_Clock_Input - Usage type In - Tells the model what to expect in the clock_times argument. - List Type includes values "None", "Times", "Wave" - "None" - legacy IBIS 7.0 behavior - "Times" - clock ticks from DQS will be in clock_times as an input - "Wave" - waveform from DQS will be in clock_times as an input Walter noted other possibilities included the models only supporting "None" and "Times" or only supporting "None" and "Wave". He had not included the option for the model to only support "Wave" and or "Times". That is, he had not allowed for the model to not support "None" and therefore not support legacy IBIS 7.0 operation. However, he was willing to discuss any combination of options people thought we should allow. Arpad confirmed that the entire DQS waveform might be passed in using the same clock_times argument, in the case of "Wave". Walter agreed. Wei-hsing asked about the lengths of the arrays, since clock ticks and the full waveform would have different lengths. Walter said the spec defines the size of the array in those two cases, and tools would have to get it right. Michael asked for confirmation that only those three choices ("None", "Times", "Wave") were valid, and that "None" was the default. Walter said those were the only choices, but that the model maker could specify whichever they wanted as the default. Walter said that if the parameter is not provided in the model, then the default behavior is IBIS 7.0 behavior, i.e., "None". slide 6: Block Diagram from Fangyi's GetWave2 proposal The slide shows that a GetWave model using clock_times as an input containing the DQS waveform is a drop-in replacement for a GetWave2 model. In addition, clock_times could be used to input clock ticks instead. slide 7: Advantages - No loss of functionality relative to the GetWave2 proposal - No new function signature AMI_GetWave2 - Models work in the existing IBIS 7.0 flow for tools that don't support this BIRD - DQS simulations not required in order to simulate DQ data path Bird Draft itself: The BIRD draft defines the new Rx_Use_Clock_Input parameter. Walter noted that he had included language stating that if the DQ Rx model contained this new parameter, then the corresponding DQS model must have GetWave_Exists true. He said we might not want to keep that restriction. He said he had drafted it that way initially in part because it was easier write that restriction than to explain the alternatives. Ambrish said he thought that restrictive language should be removed because the EDA tool is capable of providing the inputs to the DQ model, so the DQS GetWave isn't required. Michael said this had been one of their questions as well, did this proposal or the GetWave2 proposal include the assumption that DQS has a GetWave? Fangyi said that in the original GetWave2 proposal he had assumed the DQS model contained a .dll and GetWave. However, if it didn't, then he assumed the tool would provide a DQS pass-through .dll to provide the necessary inputs to the DQ model. Walter drafted some new language in the Other Notes: section to state that the EDA tool should effectively insert a pass-through Clock GetWave function if one does not exist. Walter noted that he was careful to use Data and Clock, as opposed to DQ and DQS, in the BIRD draft to keep it generic to any clock forwarding applications. Michael asked how a DQ Rx model would know what its corresponding DQS Rx model contained, or even what its corresponding DQS model was. Walter said this could be a tricky question. He said for memory side model makers its straightforward. Controllers, on the other hand, can have multiple DQS outputs and you have to know which DQS goes with DQs for writes. He said his tool stored this information in a timing model, so the tool knows what DQS belongs to what DQs. Michael noted that Walter had said the tool had the timing model. He said this was a case where the model maker can't provide that information, that is, a memory vendor's model can't know a priori the DQS associated with a particular DQ. He asked if this came down to the user defining the topology. Walter agreed that it did, and said the tool customers know the relationships and go the data book for their particular controller. They then make the correct associations in the tool, and the tool stores the information in a timing model. Walter noted that IBIS doesn't support the concept of a timing model. Arpad said it's not a question of IBIS not supporting something, it's really a simulation set-up issue for the user or tool. Walter agreed, and noted that in slide 6, the block diagram from the GetWave2 proposal, we have to know that DQS0 goes with DQ0 through DQ7 and DQS1 goes with DQ8 through DQ15. Fangyi asked if we need the "None" value for the new parameter at all, as this is just the legacy behavior. Ambrish agreed, he said if the parameter isn't there it's assumed "None" (legacy behavior). He asked if all models were required to support "None" and said that it's not as trivial as it sounds, since the model will be providing a CDR in that case. Walter said, yes, the model still needs to support "None" in case it is called upon to do a DQ simulation without a DQS path. Ambrish said a model supporting "None" is essentially saying that it doesn't need all this new stuff, and it can compute accurate enough results using its internal CDR. Arpad said that for brainstorming or prototyping it would be much easier if the parameter supported all three options than it would be if you had to remove the parameter altogether to get the "None" behavior. Walter noted some thoughts for memory vendors. He said for controllers, on reads, it has the phase interpolator (PI) and knows how to adjust the fine skew to center the DQS clock in the DQ UI. However, for writes, we need to know the N*UI skew, and advanced models that want to know all the subtle effects in fine skew will want the DQS waveform too. A memory model maker might want to consider having their DQ Rx model contain an internal CDR that can shift the "recovered clock" on its own to get it aligned with the data. That would miss some of the subtle DQ to DQS effects, but it could report back a single value to indicate the skew. Then that value could be used by the EDA tool in a second simulation that can take this effect into account. He said this was just an idea for a possible flow. Fangyi confirmed that the output of the clock_times argument would be unchanged by this proposal. Walter agreed. Arpad asked Fangyi if he thought Walter's approach would work and would cover all the issues Fangyi had outlined in his presentation. Fangyi said that he thought it would, and he thought Walter's proposal was a combination of the clock ticks only and GetWave2 approaches. Fangyi said he would have to review it in detail and discuss it with others to be sure. Arpad said he would too, and he said he liked the idea of Walter's proposal. Radek asked if the new BIRD discussed the issue of allocating the memory for clock_times. Walter said the EDA tool has always been responsible for the allocation, and it will have to be smart enough to allocate the right amount depending on the setting of Rx_Use_Clock_Input. Arpad agreed with Radek that we have to carefully review the existing language to make sure it covers this extension. Arpad asked Walter to send the presentation and updated BIRD draft to the ATM list. Walter agreed. Arpad said he would send Steve Parker an email asking him to post them to the ATM work archives. - Ambrish: Motion to adjourn. - Michael: Second. - Arpad: Thank you all for joining. AR: Walter to send his "BIRD_DQ_DQS_Clocking" presentation and BIRD draft to the ATM list. AR: Arpad to ask Steve Parker to post Walter's documents to the ATM work archives. ------------- Next meeting: 14 April 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives